Certain business software may be built around a premise of presenting data from a relational database to users. The relational database may allow editing of such data while enforcing various rules such as validation, etc., and also enabling automation and/or reporting based on the data. Additionally, certain systems may be written by software developers who first model the data in a relational database management system (RDBMS), then build business logic and a user interface in a high-level programming language (e.g., C++, C#, JavaScript, etc.). In order to modify such a system, the developer may use tools to modify a schema of the database. After schema modification, the developer may then modify business logic and user interface (referred to herein as “UI”) code to appropriately reflect these changes. With conventional applications, combined functionality from multiple different systems may prove challenging. In certain cases, custom code may be written, or middleware and/or custom front-ends may be employed to create an appearance of integration between systems. Other techniques may involve storing data descriptions, business logic, and UI definitions in metadata, which may describe the operation of the system. This metadata may be definitions stored in the RDBMS (schema, constraints, etc.) or may be stored in other formats, such as XML. To this end, changing the metadata may enable changes to the behavior and/or operation of the application (e.g., via graphical user interface (GUI) tools) to be made.
This metadata approach may allow for extension of the system by non-programmers, and in certain implementations, the metadata definitions may be extended to handle new business constructs and concepts beyond the original scope of the system. Thus, each instance of the software application, which may include the same underlying object code, can appear and behave differently depending on its respective metadata definitions. However, it may be difficult to use new definitions to describe new functionality and make it operate appropriately with changed definitions for each different instance. For example, since new functionality may interoperate with existing definitions, the new functionality may be unable to rely on any common properties to be present or to be named consistently. Furthermore, in situations where the modifications may directly modify existing functionality, integration may prove increasingly challenging. In some cases, an expert may manually reconcile changes to the system by building the same changes from scratch into the target system. Such an individual may manually update definitions, rules and user interface. However, such an approach may be costly in terms of time and effort.